home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 7344 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.6 KB  |  97 lines
  1. Path: arlut.utexas.edu!usenet
  2. From: Lee Crites <crites@arlut.utexas.edu>
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Is there a standard for * and & placement style?
  5. Date: 22 Feb 1996 19:57:14 GMT
  6. Organization: Applied Research Laboratories - The University of Texas at Austin
  7. Message-ID: <4gihqq$1s9@ns1.arlut.utexas.edu>
  8. References: <3128BD31.4AF8@wildfire.com> <marnoldDn27q9.Is0@netcom.com> <4gckd5$bc7@clarknet.clark.net> <marnoldDn63vB.H6n@netcom.com>
  9. NNTP-Posting-Host: squid.arlut.utexas.edu
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.1N (X11; I; HP-UX A.09.01 9000/730)
  14. X-URL: news:marnoldDn63vB.H6n@netcom.com
  15.  
  16. For me, I prefer to put the * with the type.  So I prefer things like:
  17.  
  18.     char* FirstName;
  19.     struct goober* goo;
  20.  
  21. But then again, I only do one per line, just as Matt was stating in his
  22. message. I also like to include initialization with the variable declarations
  23. if at all possible.  Yes, I know that c++ includes initialization, but I don't
  24. trust it.  Plus, I use languages that *don't* have that feature, so to keep my
  25. code consistent, I initialize all variables.
  26.  
  27. >Some may think "one concept per line" to be silly, but I've found it
  28. >also makes maintaining code a bit simpler (for less intra-line edits, 
  29.  
  30. Not only have I found that it is not silly, but when I have to maintain someone
  31. else's code I am sometimes forced to resturcture it just to figure out what
  32. they were trying to do.  When you hear people say that things like "...it'd
  33. just be faster to write it from scratch than to try to fix the original
  34. program..." you are hearing someone who has been bitten by this kind of bug.
  35. Even the most obtuse program can be more easily maintained if it is structured
  36. properly.
  37.  
  38. >Just because the langauge allows a particular syntax does not mean
  39. >you have to use it or structure your coding practices around it.  I
  40.  
  41. I have to add my wholehearted support to what Matt said here.
  42.  
  43. We work in multiple languages.  At this time I am actively working on
  44. programs/systems in C, C++, Pascal (BP7, TP5, and TP6), PAL, and PICKBasic.
  45. (and I have just talked with someone who would like some stuff done in either
  46. logo or lisp)
  47.  
  48. The trick is to find a *style* that works and use it in *all* of your
  49. programming.  I have a c/c++-programmer-type here that loves to ride me because
  50. I write a slightly different style of code than he does.  But my indentions
  51. look the same in all of my programs.  Period.  It is logical enough that anyone
  52. can follow what I am doing.  In fact, if it wasn't for the fact that this guy
  53. loves to ride my case about using pascal, he'd probably have never noticed that
  54. my indention style is not the same as his.
  55.  
  56. Getting a convention and sticking with it is the only way that you can write
  57. and maintain large programs.
  58.  
  59. But the most profound statement above is "...just because the language allows a
  60. particular syntax doesn't mean you have to use it..."!
  61.  
  62. How often have we seen things like "while (*a++ = *b++) ;" used?  No comments,
  63. no explainations, just cryptic code.  We are no longer in a position where we
  64. have to hand optimize our code.  We no longer have to worry about a byte of ram
  65. saved here and a byte of ram saved there.  (real-time embedded systems are an
  66. exception to this, of course)  We aren't writing programs that will run on an
  67. 8088 with 64k of ram any more.  We aren't having to trim characters out of our
  68. source files because the compiler can't handle a file that big or the diskette
  69. only holds 160k.  I remember those days, as do many of you.  They are
  70. thankfully gone.
  71.  
  72. It's time that we woke up and realized that maintainability is more important
  73. than saved keystrokes.  It's time we realized that packing a dozen, or more,
  74. commands into a single line of code isn't the quintessential sign of manhood it
  75. was once thought to be.
  76.  
  77. We need standards that help us to maintain the code.  Things like:
  78.  
  79. -- each line of code performs only one command
  80. -- use brackets to specify order
  81. -- use intelligent variable names
  82. -- include lots of internal docu
  83. -- paragraph and indent structures, including blank lines; use a standard
  84.    style throughout all code
  85. -- each method/subroutine should do one thing, and one thing only
  86. -- each method/subroutine should be small enough that it can be totally
  87.    understood in 30 seconds or so
  88. -- objects should hide all variables and constants behind accessor methods
  89. -- all program variables should be initialized
  90. -- in objects the constructor should initialize all variables
  91. -- keep casting to a minimum (if you *need* an int, make an int, not a char)
  92.  
  93. The list can go on, but I think you get my drift.
  94.  
  95. Lee
  96.  
  97.